Subject: DLSw MIB Input

From: "Deirdre Kostick" <dck2@ginsu10>
Date: Mon, 31 Oct 94 09:37:14 -0500

Folks --

Alan Sciacca just sent a note
with his contribution that
he had posted before 10/21/94.

Sorry -- I didn't see the attached --
not sure if there was a problem locally
here with my system or with the mailing list,
so I've attached his message.

Deirdre
[email-masked]

===========================forwarded mail=========
To: [email-masked]
Cc: [email-masked]
Subject: reliably applying DLSw capability changes
Date: Fri, 21 Oct 94 08:32:41 -0400
From: [email-masked]

There are a number of DLSw capabilities that may be configured (or changed) 
from SNMP management stations.  Whenever the capabilities of a particular 
DLSw entity are changed, the new capabilities must be conveyed to all the
peers of that DLSw entity.  Conveying the new capabilities to the peers
of a DLSw entity requires the DLSw entity to initiate a DLSw protocol 
exchange to each of its peers.  DLSw capabilities messages are used during
the DLSw protocol exchange.

If a DLSw entity originated new capabilities exchange messages whenever
a SNMP manager changed a capability, the frequency with which the DLSw entity 
originates capability exchange messages could be excessive.  
To prevent this situation, a number of TruthValue MIB variables were proposed
for the DLSw MIB's SNMP node "set".  The SNMP manager configures (or changes)
a number of DLSw capabilities and then sets the appropriate TruthValue variable
to initiate the DLSw protocol exchange.

Unfortunately, a single SNMP management station may use different SNMP messages
to set the TruthValue variables and the DLSw capabilities. The order in
which the SNMP agent in the DLSw entity receives these messages can differ from
the order in which the SNMP management station sent the messages because the 
SNMP protocol makes use of UDP/IP as contrasted against TCP/IP which would
guarantee order.  If the TruthValue was set before the new DLSw capabilities in
a DLSw entity, the DLSw entity may never convey the new DLSw capabilities to its
peers.  Although the SNMP protocol allows one message to set multiple variables,
most of the popular SNMP mangement station "applications" do not give their 
users access to this SNMP feature.

Furthermore, SNMP is a datagram protocol and multiple SNMP managers can
concurrently interact with a SNMP agent.  In situations in which multiple
SNMP managers set these TruthValue variables, each DLSw protocol exchange will
correspond to fewer of the changed DLSw capabilities.  

Most SNMP management stations retransmit SNMP commands whenever a SNMP reply
to the command is not received in a timely fashion because SNMP messages can
be lost due to the unreliable nature of the underlying protocols (i.e., UDP/IP)
that SNMP uses to exchange messages.  Whenever the reply to an SNMP command is 
lost, an SNMP command can be duplicated by a retransmission of the original SNMP
command.  If the SNMP command that sets the TruthValue variable(s) is 
duplicated, the DLSw entity that receives the duplicate command may 
significantly increase the DLSw protocol traffic duplicating the DLSw protocol 
exchange to each of its peers.
Moreover, the user of most SNMP management platforms will required to set
two variables to change a single capability in a DLSw entity.

All the problems that are associated with the TruthValue parameters can be
alleviated by changing them to INTEGER variable(s) that represent the time that
a DLSw entity will wait after having honored a SNMP command to change a DLSw 
capability so that the DLSw entity can honor additional SNMP commands before the
DLSw entity initiates DLSw protocol exchanges to convey the new capabilities to 
its peers.  Furthermore, all the TruthValue variables that were previously used
to initiate the DLSw capability protocol exchange can be represented by a single
INTEGER time variable.

The functionality of the timing function that corresponds to the new INTGER time
variable still needs to be addressed.  After having honored a SNMP command that
changes capabilities and started the timer, a DLSw entity could simply wait and
subsequent SNMP commands that arrive would have no effect on the timer.  
Whenever the timer expires, the DLSw capability protocol exchange would take 
place.  A timing function with this functionality establishes the maximum 
frequency with which SNMP commands can provoke a DLSw entity to initiate DLSw 
capability protocol exchanges to its peers.  However, a timer function with 
this functionality can prolong the time required for a single capability change
to take effect. (E.g., the SNMP manager must trade-off between larger timing 
intervals that minimize the frequency with which the DLSw protocol is used to 
make the new capabilities take effect and smaller timing intervals which 
minimize the latency with which a single DLSw capability change takes effect.)

To eliminate the need for this trade-off a DLS entity should restart the timer 
whenever it honors subsequent SNMP commands that change DLSw capabilities.  With
this functionality, a reasonably small timer value could be used to minimize the
latency with which a single DLSw capability change takes effect and the timeout
is prolonged whenever other SNMP commands to change DLSw capabilities arrive 
before the timer expires. 

Alan Sciacca